前四天跟大家聊很多觀念與思考一些議題，今天要來聊聊 CI 該怎麼開始了！
要開始 CI 並不難，最簡單的方向：只要每次修改程式到一個段落都做驗證，這樣就是 CI 了。 Day 2 介紹 CI 有提到， CI 很像對程式做健康檢查。當健康檢查越頻繁的時候，就越容易知道病源在哪裡。比方說：昨天健檢身體很健康，今天突然發現腸胃有點毛病，這時可能會懷疑昨天晚上吃燒烤的味道好像怪怪的，但絕對不會懷疑前天吃的火鍋不新鮮。
是的，這就是頻繁驗證最大的好處：縮小並聚焦問題可能發生的範圍。很多寫程式的老手都會不自覺使用這個方法在除錯。比方說下面這段程式碼：
<?php
function foo($param)
{
// many code
$val = bar($paramBar);
// many code using $val
}
function bar($param)
{
// many code
}
$output = foo($paramFoo);
在執行 foo() 的回傳值或過程不正確。這時也不知道該懷疑 foo() 還是 bar() ，所以最快的做法就是在 bar() 上面加一行 code ：
var_dump($paramBar);
$val = bar($paramBar);
接著再跑一次，確認 $paramBar 值是對的後，再加一行：
var_dump($paramBar);
$val = bar($paramBar);
var_dump($val);
確認 $val 值沒錯後，好了，可以確定是 foo() 後續處理的問題了！這正是頻繁驗證的一種。
大家可能會想說，上面這招只要是有經驗的都會知道，還輪得到我講嗎？確實，也許大家都很常用，但只有單純做頻繁驗證的話，會有一個魔鬼細節：驗證範圍。以上面程式碼和驗證方法為例，它只能驗證在同一個 $paramFoo 下， bar() 與 foo() 是正確的。但這個程式碼應該還要驗證：
$paramFoo 也會如預期輸出嗎？$paramFoo 也會如預期丟例外嗎？foo() 的程式都全都有如預期執行嗎？前兩點還好，改個參數丟一下，結果還算很快就出來了。第三個該怎麼辦，還要全域搜尋所有程式去一個一個驗證，正常人應該都會受不了，就跟要求要天天去全面性健康檢查，不管是誰都無法接受。
咦？我們的目的是要一直不斷做同樣的檢查，這不正是電腦所擅長的事嗎？所以我們可以寫測試程式來驗證程式是否正確，並讓電腦幫我們驗證，這就是「自動化測試」。當每次驗證的範圍都夠大的話，就可以確保程式在這個範圍下會如預期執行了。
當有了自動化，相信做驗證對任何開發人員來說都不難。但要記得，每次的驗證結果都應該要被記錄下來，供未來參考。可以回想上面頻繁驗證的例子，我們也是先驗證 bar() 功能正確，再依此結果去推論 foo() 是有問題的，因此記錄結果是有必要的。
要開始記錄前，必須要有一個系統可以做程式碼開發的歷程回顧。是的，就是 Version Control System ，也稱為原始碼版本控制系統，通常簡稱為「版控系統」或直接叫「版控」。這部分的實作有很多選擇，如 Subversion 、 Git 、 Mercurial 等。使用版控系統的好處很多，當然最大的好處在資訊分享：可讓團隊成員取得軟體的原始碼、自動化程式碼和開發歷程。
那什麼時候該記錄驗證結果呢？其實答案也是呼之欲出：當提交程式碼到版控系統時，就能記錄了。版控系統的提交資訊也可以結合驗證結果的資訊，並分享給團隊成員，讓大家可以避免拿到驗證失敗的程式碼，同時也能取得足夠的資訊繼續開發。目前常見的 SaaS 版控系統都有做這一類的服務，如下圖是 GitHub + GitBook 的範例。
Day 4 提到了「先要對，才會有」。而對工程師而言，程式碼要先驗證通過，才能提交程式碼進版控系統，這時就可以跟團隊成員說功能已經「有」了。
相反地，提交驗證不通過的程式碼，是在把 bug 分享給團隊成員。而其他人修改程式發生問題時，也很難去鎖定問題的範圍。比方說上例程式，如果不知道 bar() 是不是對的，就無法確定 foo() 是否有問題。對除錯來說，只要有越多的疑惑，障礙就越大。但只要養成良好習慣：驗證通過，才提交程式碼，這樣就能更有效率的開發，同時也避免風險擴大。
人並不完美，自動化是人寫的，或多或少會遺漏必要的驗證。如果已經知道取得的程式碼有問題了，最好的決策就是立即修復它，而不要在知道有問題的狀況下加新功能，因為這很有可能會讓 bug 擴散到新功能裡。
另外，還有一個重要理由是，只要團隊接受程式有任何小錯誤，接著可能會有人開始提交錯誤程式碼，反正有人會接受嘛！最終就會像破窗效應所說的，整個團隊會開始不在乎程式是否有錯。當這個文化被建立時，要做到頻繁驗證就會是天方夜譚了。唯有強迫團隊對任何錯誤都視為優先解決目標，才有辦法建立起良好的 CI 文化。
原始碼要包含所有能讓開發者可以自己執行驗證的資訊，如使用套件或驗證腳本等。主要是因為：要能讓開發者自行確認程式是否正確，並方便地在自己開發主機上做頻繁驗證。除此之外，另一個原因是要能讓程式碼在不同的地方都能執行驗證，如新進成員的電腦、或是 CI Server ，甚至是產品上線環境裡等。
上面已經提到很多有關驗證除錯的好習慣。最後，就是要養成常常提交與更新程式碼的習慣了！這背後有很多重要的原因：
前面提到的一些要領，是參考自 CI 的經典名著－－ Continuous Integration 並用個人想法表達出來的，原文裡面有提到開發人員所要遵守的七大要領：
有興趣的話，可以翻這本書了解原作的想法與細節。
七大要領的說明也可以參考 Teddy 寫的開發人員應遵循的七項持續整合要領。
當然，驗證不能只是說說，團隊必須要決定驗證什麼樣內容，才有辦法做持續驗證，因此：
下一篇： CI 起步走
iThome鐵人賽
看影片追技術